Packet-based communication protocols are widely used for a multitude of different types of communications. These protocols often use a Cyclic Redundancy Check (CRC) value that is transmitted along with each packet so that the packet can be verified (via the CRC) by a device receiving the packet, helping to insure the integrity of the data contained in the packet. For packets with a non-trivial length, devices transmitting these packets incrementally compute the CRC value as the device processes each data element of the packet. After the last data element of the packet is processed, the resulting CRC value is a nearly unique value representing the contents of the packet.
The CRC usually is transmitted at the end of the packet. A device receiving a packet can perform the same CRC computation on the incoming packet and verify that the computed CRC matches the transmitted CRC value received with the packet to ensure that the packet data was not corrupted during transmission. If the computed CRC does not match the received CRC value, then the data is determined to be corrupted and an error recovery mechanism is generally employed.
A variety of different protocols are implemented in connection with packet-based communications. Some protocols, such as Mobile Industry Processor Interface (MIPI) UniPro or PCI Express, support several independent packet streams to be transmitted over a shared physical link. Arbitration between the streams is often used to ensure that complete, uninterrupted packets are sent over the link, or to ensure that higher priority packets interrupt lower priority packets (i.e., preemption) as allowed in MIPI UniPro. The receiving device is notified of preemption through the framing symbols around the packet.
A pair of packets where a high priority packet preempts a lower priority packet might be signaled with the sequence illustrated in FIG. 4B.
The CRC computation may cover all framing symbols and data elements as does MIPI UniPro.
While useful for a variety of packet-based communications, various issues have presented challenges to these approaches. For instance, packet streams from different priority classes may be pipelined in hardware so that the CRC may be computed on the data elements prior to presenting the data element to the packet arbiter. When the arbiter switches to a different packet stream, the interrupted packet may be required to insert a COF symbol which may be included in the CRC computation. If the CRC computer has already processed the data elements that are immediately after the COF, the computer must “undo” the last CRC computation or restore an old CRC value, then process the COF symbol and continue with the packet. This “undo” to insert a COF symbol generally causes a delay or requires additional storage elements. If the extra delay in the low priority packet is avoided by cleanly inserting the COF earlier in the pipeline, the higher priority packet is delayed while the data elements which have already contributed to the CRC computations in the lower priority packet pipeline can be transmitted.
These delays, additional required storage elements and other related characteristics of CRC-based packet communications have continued to present challenges to packet-based communications as well as devices and systems employing the same.